I think I'd have the exact same issue if my app was fed strings like this. Also would be particularly scared of using - (NSUInteger)indexOfObject:(ObjectType)obj inSortedRange:(NSRange)r options:(NSBinarySearchingOptions)opts usingComparator:(NSComparator)

I filed FB24921668

Indeed. I checked for a url with an empty string but when I call URLByDeletingLastPathComponent on a file path url with only 1 component it does not return a url like that - it appends a path component with **.. ** And if you keep calling URLByDeletingLastPathComponent on the resulting URL (like I did in the dumb little sample above) it will continue to do so so you'll get file:///../../../../../ to infinity which is...weird. This looks like a bug to me but at the very least the documentation should be updated to document IMO.

Hm, sometimes search just gets stuck. I get a NSMetadataQueryDidStartGatheringNotification but no NSMetadataQueryDidFinishGatheringNotification. To follow up - it may have not actually been stuck. I let it ride for around 30 minutes and finally got the 1 search result I was expecting.

Hm, sometimes search just gets stuck. I get a NSMetadataQueryDidStartGatheringNotification but no NSMetadataQueryDidFinishGatheringNotification. Seems to happen when testings on a particular volume mount... Finder is able to get results for it. (but another volume mount works fine, both are SMB shares). I'm not doing anything extravagant - applying the same template predicate for the search every time. And then there are times I get results brilliantly fast. Extremely frustrating. Feels like a magic box that works like 70% of the time. I filed a bunch of feedbacks against this API: FB24729304 FB24493001 FB24349840 FB24690162 FB24349840 I probably will file more against NSMetadataQuery soon. kind of disappointing spending so much time on this but may end up having to abandon.

I got an email asking for FB20356742 asking me to verify the issue. I was hoping that maybe it got fixed with Golden Gate but it appears nothing has changed. Edit: on further inspection... the copies of these helper apps I'm seeing are buried in Xcode's 'Derived Data" folder. I cleared out derived data - now they don't show up in "Apps" so maybe it is fixed. Maybe .app builds in Derived Data should be excluded too but that is a separate bug. I closed FB20356742 !

Turns out enabling fieldEditor is actually useful for what I was after (I added a comment to my previous post explains why). So it wasn't really a complete mistake on my end to turn that on. I just discovered that the behavior I saw--just single clicking in certain areas and all the text selects might be considered standard field editor behavior when you click in the empty region surrounding the text (specified by the text container inset). I can easily reproduce it in Finder's search field. If you type some text in Finder's search field and carefully click in the empty region above the text - all the text in the search field selects (including all tokenized text if there is any). I assume the field editor being used with the search field has text inset since there seems to be some vertical padding there. This select all behavior went against my intuition but I get the sense that it might actually be the intended behavior. Looks like I might've been on a wild goose chase.

It turns out I made a silly mistake. A couple weeks ago I was experimenting a bit and set fieldEditor property to YES. The behavior is caused by fieldEditor being YES and specifying a textContainerInset. I don't have any reason to have fieldEditor set to YES so just removing that line fixes the issue. Thanks again for taking the time to reply!

So it does appear to be related to setting the textContainerInset. If I take that out haven't been able to reproduce the weird one click selects all issue. I do need to add a bit of inset so typed text aligns properly for this UI. I moved the text view's scroll view to a container view so I can add the other view that was previously a floating subview to the container next to it (so I no longer need to set textContainerInset.width) but I still need to adjust textContainerInset.height a tiny bit to get proper appearance. But as soon as I set textContainerInset (just with a little height and no width this time) it all falls apart again.

Thanks a lot for the detailed reply. Adding -ensureLayoutForTextContainer: call in -mouseDown: before calling super does not make the problem go away. I do have a somewhat complicated subclass and I override cursorUpdate: to make sure the IBeam cursor isn't showing when the mouse hovers at certain points around my token cells. But I commented all that out and I still get the selection behavior issue. I commented out my other complex customizations but the issue persists. I am insetting the textContainer a bit to make room for a floating subview I add to the scroll view and wonder if that is somehow related.

I am able to get the agent to work though it gets confused about its environment and responds with things like: "The files aren't found. Let me check if this is a macOS project and the files might be in a different location. The working directory is on Linux but the paths look like macOS. Let me check what's actually in the current directory." The agent is able to find the files mounted in the container with a little bit of effort though. But still the second message I send from Xcode causes a failure every time with that error: *** JSON-RPC global stream failed: The operation couldn’t be completed. (IDEIntelligenceProtocol.JSONRPCElement.Error error 1.)** I have not investigated the Hermes code myself but I did feed the error log to an LLM (so take this diagnosis for whatever it's worth: Quote below is from AI: **"Your log proves Xcode sent a cancel: 14:46:42 Cancelled session b05d... 14:46:43 Prompt on session b05d... 14:46:43 Turn ended: reason=interrupted_by_user The previous turn had completed at 14:41:35, more than five minutes earlier. ACP defines session/cancel as cancelling an ongoing prompt turn. Since no turn was running, Xcode’s cancellation appears stale, unnecessary, or part of its cleanup behavior. However, Hermes should safely tolerate that. Its current cancellation handler: Sets cancel_event. Calls agent.interrupt(). Does so even when state.is_running is false. The is_running check only controls whether Hermes saves current_prompt_text; it does not prevent the interrupt. When the next prompt begins, Hermes clears: state.cancel_event.clear() but does not clear the internal agent interrupt state. That explains why the second turn immediately reports: reason=interrupted_by_user and then throws: acp.exceptions.RequestError: Internal error Responsibility Xcode is the trigger: it sent a cancellation when Hermes apparently had no active prompt. Hermes is responsible for the failure: an idle or stale cancellation should not poison the next prompt or terminate the JSON-RPC request with an internal error. Xcode’s displayed error is only the consequence: its ACP peer returned an unhandled internal error, so Xcode reported the generic “JSON-RPC global stream failed.” I would report this primarily as a Hermes ACP bug, while explicitly noting that Xcode sends an idle session/cancel immediately before the next session/prompt. A robust fix is for Hermes to ignore cancellation when state.is_running is false and clear any stale internal interrupt state at the beginning of a new prompt. "** Figured I'd share. Would be cool to have a working local AI set up in Xcode. So close.

So I have my agent in a Docker container which makes set up with Xcode more difficult I think. Also hermes agent + Xcode fails every time on the second turn with: ** JSON-RPC global stream failed: The operation couldn’t be completed. (IDEIntelligenceProtocol.JSONRPCElement.Error error 1.) ** This may be a bug in Hermes and not Xcode. Not sure. But either way I think I'm throwing in the towel for now though. If anyone has pointers on getting Hermes (in Docker) + Xcode to work properly let me know. I don't want to move the agent out of the container.

Thanks for the recommendation! I just set this up as a custom ACP Agent in Xcode. Hoping to get better results now.

So switching to 'App Information' and adding the localization there worked. Now adding the localized app description and screenshots doesn't fail. That's the workaround I guess.

Can you also file a bug with your description for the team? Sure no problem. FB23519126